Code Review

Overview

Fixes #628: a virtual field named in a caller-supplied include (e.g. context.db.myList.findMany({ include: { myVirtualField: true } })) used to be forwarded straight to Prisma and throw Unknown field at runtime, since virtual fields have no database column. This PR adds stripVirtualFieldsFromInclude() (in access-filter.ts) and applies it as the final step before model.findFirst/model.findMany in context/index.ts, covering all three paths that can produce include (fragment-built, access-controlled merge, sudo passthrough).

Correctness

• Core logic is sound. The strip check (fieldConfig?.virtual) runs before the relationship check, so a virtual field is dropped regardless of whether its value is bare true or an object — matches all the ways a caller could name it.
• Nested relation includes preserve non-include keys correctly. The recursive branch spreads the original value (not the narrowed entry from asEntryObject) and only overrides include, so where/orderBy/take/skip/select on a relation entry survive untouched.
• findFirst is covered for free since it delegates to the fixed findMany. createGet (singleton) doesn't accept a caller include and its auto-built include only ever contains relationship keys, so it's correctly left untouched.
• The sudo passthrough fix is a real, distinct improvement — previously sudo used args.include completely unfiltered, so this bug applied there too. Good that it's covered by both the fix and a dedicated test.

Test coverage

Five new regression tests in context.test.ts under virtual fields named in include no longer reach Prisma (#628):

• findMany/findUnique with a virtual field + real relationship in include → virtual key stripped, relationship include intact, virtual value still returned.
• Virtual value populated when omitted from include (pre-existing behavior, now guarded against regression).
• Sudo path strips the virtual key while leaving the real relationship passthrough unfiltered (matches documented sudo semantics).
• Read access control on a virtual field still applies.

This satisfies all the acceptance criteria from the issue's triage brief. Full suite (729 tests), tsc build, and lint all pass with no regressions.

Minor/non-blocking observations

1. Unresolvable related config skips nested stripping. If a declared relationship's ref can't be resolved via getRelatedListConfig (unlikely — config validation should prevent a dangling ref), the nested include under that relation is passed through without recursing. This mirrors an existing fallback pattern elsewhere in the codebase (e.g. filterReadableFields's "Related config not found, include the value as-is" branch), so it's consistent rather than a new gap.
2. Nested select inside a relation include entry (Prisma also supports { include: { posts: { select: {...} } } }) isn't scanned for virtual keys. Out of scope per the issue — worth a follow-up only if that usage becomes common.

Security

No concerns — this only narrows what reaches Prisma; it doesn't loosen any access control path. Field-level read access on virtual fields and relationship-level access filtering both remain intact and tested.

Verdict

Solid, minimally-scoped fix with good test coverage matching the issue's acceptance criteria. No blocking issues found. Approving.

Generated by Claude Code